@怪人
2年前 提问
1个回答

作为识别潜在漏洞条件的依据有哪些

Ann
2年前

以下这些可以作为识别潜在漏洞条件的依据:

  • HTTP状态码:Web 服务器的请求响应包含一个三位数字的代码以标识请求的状态。在 RFC2616-超文本传输协议-HTTP/1.1的第十部分可以找到完整的状态码列表。状态码可以提供确定哪些模糊请求需要进一步研究的线索。例如,一系列 500 错误(表示“内部错误”的状态码)可能意味着前面的请求导致服务器发生错误。401错误(表示“未授权错误”的状态码)则意味着被请求的页面存在,但是受密码保护。

  • Web服务器错误消息:Web应用可能会直接在Web页面内容中显示错误消息。使用正则表达式来解析包含在响应中的HTML可以找到这类消息。

  • 中断连接:如果某个模糊测试输入导致Web服务器挂起或发生崩溃,后续请求将不能成功地连接到服务器。因此,模糊测试工具应当维护日志文件,记录管道中断或是连接失败事件。当查看日志文件并发现一系列的连接失败后,就可以直接查看刚好在发生错误的日志条目之前的请求,确定故障所在。

  • 日志文件:大多数Web服务器可以被配置为记录多种类型的错误。这些日志同样可以提供发现哪些模糊请求会导致一个可被利用的条件发生的线索。使用日志文件所面临的难点是无法直接根据日志文件找到导致错误的请求。将请求和错误日志联系起来的一个可行方法是,将攻击计算机和目标计算机的时钟进行同步,查看请求和日志条目的时间戳,这样可以缩小需要检查的范围,但它仍然不能准确、确定地将某个模糊测试请求关联到它导致的故障。

  • 事件日志:事件日志也不能直接对应到相应的请求,但可以通过时间戳关联到特定事件,在这一点上它与Web服务器日志类似。微软的Windows操作系统使用了事件日志,可以通过事件查看器(Event Viewer)应用查看事件日志。

  • 调试器:鉴别已处理和未处理异常的最好方法是,在开始模糊测试之前将目标应用连接到调试器。错误处理机制可能会掩盖模糊测试导致的许多明显的故障表现,但通过调试器通常可以发现这些错误。寻找已处理的异常和寻找未处理的异常同样重要,因为错误处理机制会处理某些特定类型的错误,如解引用空指针以及格式字符串引发的异常,但如果给定恰当的输入,它们也可以成为可被利用的漏洞。和上面的异常检测方法一样,这里面临的最大挑战仍然是确定哪个请求导致异常的产生。在Web应用模糊测试方面调试器有一定的局限性,因为调试器可以发现服务器的异常,却不能发现应用层的异常。